<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>Limitations</title>
<link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset">
<link rel="up" href="../atomic.html" title="Chapter&#160;4.&#160;Boost.Atomic">
<link rel="prev" href="usage_examples.html" title="Usage examples">
<link rel="next" href="porting.html" title="Porting">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table cellpadding="2" width="100%"><tr>
<td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td>
<td align="center"><a href="../../../index.html">Home</a></td>
<td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td>
<td align="center"><a href="http://www.boost.org/users/people.html">People</a></td>
<td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td>
<td align="center"><a href="../../../more/index.htm">More</a></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="usage_examples.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../atomic.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="porting.html"><img src="../../../doc/src/images/next.png" alt="Next"></a>
</div>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="atomic.limitations"></a><a class="link" href="limitations.html" title="Limitations">Limitations</a>
</h2></div></div></div>
<p>
      While <span class="bold"><strong>Boost.Atomic</strong></span> strives to implement the
      atomic operations from C++11 as faithfully as possible, there are a few limitations
      that cannot be lifted without compiler support:
    </p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
          <span class="bold"><strong>Using non-POD-classes as template parameter to <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="identifier">T</span><span class="special">&gt;</span></code>
          results in undefined behavior</strong></span>: This means that any class containing
          a constructor, destructor, virtual methods or access control specifications
          is not a valid argument in C++98. C++11 relaxes this slightly by allowing
          "trivial" classes containing only empty constructors. <span class="bold"><strong>Advise</strong></span>: Use only POD types.
        </li>
<li class="listitem">
          <span class="bold"><strong>C++98 compilers may transform computation- to control-dependency</strong></span>:
          Crucially, <code class="computeroutput"><span class="identifier">memory_order_consume</span></code>
          only affects computationally-dependent operations, but in general there
          is nothing preventing a compiler from transforming a computation dependency
          into a control dependency. A C++11 compiler would be forbidden from such
          a transformation. <span class="bold"><strong>Advise</strong></span>: Use <code class="computeroutput"><span class="identifier">memory_order_consume</span></code> only in conjunction
          with pointer values, as the compiler cannot speculate and transform these
          into control dependencies.
        </li>
<li class="listitem">
          <span class="bold"><strong>Fence operations enforce "too strong" compiler
          ordering</strong></span>: Semantically, <code class="computeroutput"><span class="identifier">memory_order_acquire</span></code>/<code class="computeroutput"><span class="identifier">memory_order_consume</span></code> and <code class="computeroutput"><span class="identifier">memory_order_release</span></code> need to restrain
          reordering of memory operations only in one direction. Since there is no
          way to express this constraint to the compiler, these act as "full
          compiler barriers" in this implementation. In corner cases this may
          lead to worse code than a C++11 compiler could generate.
        </li>
<li class="listitem">
          <span class="bold"><strong>No interprocess fallback</strong></span>: using <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="identifier">T</span><span class="special">&gt;</span></code>
          in shared memory only works correctly, if <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="identifier">T</span><span class="special">&gt;::</span><span class="identifier">is_lock_free</span>
          <span class="special">==</span> <span class="keyword">true</span></code>
        </li>
</ul></div>
</div>
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
<td align="left"></td>
<td align="right"><div class="copyright-footer">Copyright &#169; 2011 Helge Bahmann<br>Copyright &#169; 2012 Tim Blechmann<p>
        Distributed under the Boost Software License, Version 1.0. (See accompanying
        file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
      </p>
</div></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="usage_examples.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../atomic.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="porting.html"><img src="../../../doc/src/images/next.png" alt="Next"></a>
</div>
</body>
</html>
